Fix busy-waiting loops-#Log Aggregation #3127
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
issue This PR Solves In microservices, logs are often collected using busy waiting loops, where the system constantly checks for new logs. This leads to several issues: Wasting Resources: The system keeps checking for new logs, using up CPU resources even when there are no logs to process. Increased Latency: Logs are delayed because the system is busy checking for new data rather than processing logs as they arrive. This PR solves these problems by switching to a more efficient event-driven log aggregation system. Instead of constantly checking for new logs, the system reacts only when new logs are available, reducing unnecessary CPU usage and improving scalability and performance.
The Scheduler design pattern provides a clean and structured solution to manage and execute tasks automatically. It involves: Scheduler: A component responsible for managing the execution of tasks, ensuring they run at the correct time or under the right conditions. Task: A unit of work that encapsulates the logic to be executed. Trigger/Condition: Defines when and how often a task should execute, whether it's based on time intervals (e.g., every minute) or events Execution Context: Ensures that tasks are executed in the right environment, managing resources, states, and concurrency. By using this pattern, tasks are managed centrally, execution timing is automated, and the system can handle various triggers and execution conditions efficiently, allowing developers to focus on defining what needs to be done instead of when and how to execute it.
|
iluwatar
requested changes
Jan 5, 2025
Owner
iluwatar
left a comment
iluwatar
left a comment
There was a problem hiding this comment.
Unfortunately the changes seem to affect only README.md files, so the software behavior is still unfixed
Repository owner
closed this by deleting the head repository
Jan 5, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
in microservices, logs are often collected using busy waiting loops, where the system constantly checks for new logs. This leads to several issues:
Wasting Resources: The system keeps checking for new logs, using up CPU resources even when there are no logs to process.
Scalability Problems: As the number of services grows, busy waiting loops become inefficient and slow, causing delays and performance issues.
Increased Latency: Logs are delayed because the system is busy checking for new data rather than processing logs as they arrive.
This PR solves these problems by switching to a more efficient event-driven log aggregation system. Instead of constantly checking for new logs, the system reacts only when new logs are available, reducing unnecessary CPU usage and improving scalability and performance